這幾天，我一直在把 ARCI 往更高的層級推。

從最開始的韌性通訊，到知識層、決策編排、學習治理，再到跨系統的演化機制，系統裡的東西越來越多。

做到這裡，我突然遇到一個很根本的問題：

如果我希望 ARCI 真的能「學習」，那我要怎麼訓練它？

我第一個想到的答案其實很直覺。

是不是要開始餵它大量資料？

或者接上更多不同的 AI 模型，讓每個模型都跑一次，再從不同答案裡面選出最好的？

但後來我發現，這其實把三件完全不同的事情混在一起了。

接更多模型，不等於學習

假設今天 ARCI 同時接了：

• GPT
• Gemini
• Claude
• 本地模型
• 專門做檢索的模型
• 專門做分類的模型

它確實可能變得更強。

因為不同模型擅長的事情不同。

有的推理能力好，有的速度快，有的成本低，有的適合處理長文，有的適合程式，有的適合做結構化輸出。

如果系統能夠根據任務，自動選擇最適合的模型，它就會比「永遠只把所有問題丟給同一個模型」聰明很多。

但這叫做：

Routing。

也就是路由與編排。

不是 Learning。

因為下一次碰到同一個問題時，如果系統還是按照完全一樣的規則做選擇，它其實沒有從上一次的結果學到任何東西。

它只是很會分工。

餵很多資料，也不一定是在學習

另一個直覺是：

「那我建立一個超大的知識庫呢？」

例如災害資料、通訊資料、歷史案例、研究論文、政府公開資料、過去的決策紀錄……

全部塞進 ARCI。

這當然很重要。

因為沒有知識，模型很容易只靠原本訓練資料回答。

而 ARCI 這種系統，如果真的要被放進災害情境，更不能只相信模型「記得什麼」。

資料必須有來源、時間、版本、可信度，而且最好能知道：

這個決策到底是根據哪一筆資料做出來的？

所以我前面的 Knowledge Layer 很大一部分，就是在解決這件事情。

但即使有一百萬筆資料：

這仍然只是 Knowledge。

不是 Learning。

因為資料庫變大，不代表系統知道自己以前哪一次做錯了。

真正的學習，發生在「做完之後」

我目前對 ARCI 的「學習」定義開始變得比較清楚。

真正重要的不是：

系統知道多少東西？

而是：

系統做完一件事情之後，有沒有能力判斷結果好不好，並且改變下一次的行為？

例如某次災害通訊任務裡：

ARCI 選擇了 Route A。

結果：

• 延遲 820 ms
• 封包遺失率 12%
• 成功送達
• 但耗電量非常高

另外一次，它選擇 Route B：

• 延遲 1100 ms
• 封包遺失率 3%
• 成功送達
• 耗電量低很多

這時候真正值得留下來的，不只是兩份 log。

而是：

在什麼情況下，Route B 比 Route A 更值得選？

如果下一次又出現類似環境，系統可以因為之前的結果而調整自己的選擇，那才開始接近「學習」。

所以我真正需要建立的是 Feedback Loop

我開始把整件事情理解成一個循環：

Observe → Decide → Execute → Evaluate → Learn → Decide Again

也就是：

觀察環境
↓
做出決策
↓
執行
↓
觀察結果
↓
判斷好不好
↓
留下可使用的經驗
↓
影響下一次決策

這裡面最困難的，其實不是 Execute。

現在的 LLM 很會執行。

真正困難的是：

Evaluate。

因為如果系統連「成功」的定義都是錯的，那它學得越快，反而可能錯得越嚴重。

一個會學習的系統，也可能學壞

這件事情是我最近越做越在意的地方。

假設我們只設定一個目標：

讓訊息送達率最高。

那系統可能慢慢發現：

「只要重送很多次，成功率就會提高。」

於是下一次：

重送 5 次。

再下一次：

重送 10 次。

成功率真的提高了。

但基地台負載也爆掉了。

如果它只看單一指標，它甚至會認為：

自己正在進步。

這就是為什麼我現在不太想做那種「模型自己修改所有規則」的自主學習系統。

至少目前的 ARCI 不應該這樣。

因為 ARCI 面對的是韌性通訊與災害環境。

在這種系統裡：

學習速度沒有可控性重要。

所以 Layer 4 我做的不是「讓 AI 自己亂學」

我現在比較傾向另一種方法：

Governed Learning。

也就是「受治理的學習」。

系統可以提出：

根據最近 100 次執行結果，我建議把某種情況下 Route B 的優先權提高。

但它不能直接偷偷把 Production Policy 改掉。

這個改動必須經過：

• Evidence
• Evaluation
• Policy constraints
• Regression
• Replay
• Safety gate

最後才有資格成為新的行為。

換句話說：

ARCI 可以說：

「我覺得我學到了一件事。」

但系統還要回答第二個問題：

「你怎麼證明？」

這也是為什麼我的系統開始越做越不像 Chatbot

如果只是做聊天機器人：

User
↓
LLM
↓
Answer

其實就完成了。

但 ARCI 現在逐漸變成：

Environment
↓
Knowledge
↓
Eligibility
↓
Orchestration
↓
Decision
↓
Execution
↓
Evidence
↓
Outcome
↓
Evaluation
↓
Learning Candidate
↓
Governance
↓
Future Policy

LLM 只是其中的一部分。

這也是我最近最大的一個觀念轉變。

我以前會問：

「我要用哪一個模型？」

現在開始變成：

「我要怎麼設計一個即使模型犯錯，也不會讓整個系統一起失控的架構？」

多模型真正有趣的地方，也是在這裡

所以我還是可能會讓 ARCI 接不同模型。

只是目的不再是：

「三個 AI 回答一次，少數服從多數。」

而是讓不同模型在系統裡扮演不同角色。

例如：

Model A：提出方案。

Model B：找漏洞。

Model C：檢查證據是否支持結論。

系統本身再根據歷史結果，記錄：

• 哪一類任務哪個模型表現比較好？
• 哪個模型容易出現哪種錯誤？
• 哪個模型在什麼環境下成本最低？
• 哪些決策需要第二個模型交叉驗證？

這時候：

Multi-model 才開始和 Learning 接起來。

我現在理解的 ARCI 自主學習

所以如果現在有人問我：

ARCI 要怎麼訓練？

我的答案已經不是：

「餵很多資料。」

也不是：

「接很多模型。」

而是：

讓系統累積可以被驗證的經驗。

資料提供知識。

模型提供能力。

Orchestrator 負責決策。

Evaluation 判斷結果。

Feedback 產生學習訊號。

Governance 決定這個學習能不能真的改變系統。

這幾個東西一起存在，才比較接近我想做的 Autonomous Intelligence。

Day 06

做到第六天，我反而沒有急著再增加一堆功能。

因為我發現現在更重要的是先定義：

這個系統到底怎樣才算「真的學會了」？

如果我連這件事情都沒有定義清楚，那後面增加再多模型、再多資料、再多自動化，都只是讓一個不知道自己有沒有做對事情的系統跑得更快。

所以接下來 ARCI 真正要面對的問題，不只是：

能不能做出決策？

而是：

能不能從結果裡學習？

以及更重要的一個問題：

我能不能證明，它學到的是對的？

這可能會是接下來幾層最難的部分。

但我也開始覺得——

這才是真正有趣的地方。